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In contrast to popular belief, proving 

termination is not always impossible. 

— 

BY BYRON COOK, ANDREAS PODELSKI, 

AND ANDREY RYBALCHENKO 

Proving 

Program 

Termination 


the program termination problem, also known 
as the uniform halting problem, can be defined as 
follows: 

Using only a finite amount of time, determine 
whether a given program will always finish running 
or could execute forever. 

This problem rose to prominence before the 
invention of the modern computer, in the era of 
Hilbert’s Entscheidungsproblemf the challenge to 
formalize all of mathematics and use algorithmic 
means to determine the validity of all statements. 

In hopes of either solving Hilbert’s challenge, or 
showing it impossible, logicians began to search 
for possible instances of undecidable problems. 
Turing’s proof 38 of termination’s undecidability is 
the most famous of those findings. b 
The termination problem is structured as an infinite 


set of queries: to solve the problem 
we would need to invent a method ca¬ 
pable of accurately answering either 
“terminates” or “doesn’t terminate” 
when given any program drawn from 
this set. Turing’s result tells us that 
any tool that attempts to solve this 
problem will fail to return a correct 
answer on at least one of the inputs. 
No number of extra processors nor 
terabytes of storage nor new sophisti¬ 
cated algorithms will lead to the devel¬ 
opment of a true oracle for program 
termination. 

Unfortunately, many have drawn 
too strong of a conclusion about the 
prospects of automatic program ter¬ 
mination proving and falsely believe 
we are always unable to prove termi¬ 
nation, rather than more benign con¬ 
sequence that we are unable to always 
prove termination. Phrases like “but 
that’s like the termination problem” 
are often used to end discussions that 
might otherwise have led to viable par¬ 
tial solutions for real but undecidable 
problems. While we cannot ignore 
termination’s undecidability, if we 
develop a slightly modified problem 
statement we can build useful tools. 
In our new problem statement we will 
still require that a termination prov¬ 
ing tool always return answers that 
are correct, but we will not necessarily 
require an answer. If the termination 
prover cannot prove or disprove termi¬ 
nation, it should return “unknown.” 

Using only a finite amount of time, 
determine whether a given program 
will always finish running or could 
execute forever, or return the answer 
“unknown.” 


| key insights 


■ For decades, the same method was used 
for proving termination. It has never been 
applied successfully to large programs. 

■ A deep theorem in mathematical logic, 
based on Ramsey's theorem, holds the 
key to a new method. 


a In English: “decision problem.” 

b There is a minor controversy as to whether or not Turing proved the undecidability in 38 . Technically 
he did not, but termination’s undecidability is an easy consequence of the result that is proved. A 
simple proof can be found in Strachey . 36 


The new method can scale to Large 
programs because it allows for the 
modular construction of termination 
arguments. 
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This problem can clearly be solved, 
as we could simply always return “un¬ 
known.” The challenge is to solve this 
problem while keeping the occurrenc¬ 
es of the answer “unknown” to within 
a tolerable threshold, in the same way 
that we hope Web browsers will usu¬ 
ally succeed to download Web pages, 
although we know they will sometimes 
fail. Note that the principled use of 
unknown in tools attempting to solve 
undecidable or intractable problems 
is increasingly common in computer 
science; for example, in program anal¬ 
ysis, type systems, and networking. 

In recent years, powerful new ter¬ 
mination tools have emerged that re¬ 
turn “unknown” infrequently enough 
that they are useful in practice. 35 These 
termination tools can automatically 
prove or disprove termination of many 
famous complex examples such as 
Ackermann’s function or McCarthy’s 
91 function as well as moderately sized 
industrial examples such as Windows 
device drivers. Furthermore, entire 
families of industrially useful termi- 
nation-like properties—called live¬ 
ness properties —such as “Every call to 
lock is eventually followed by a call 
to unlock” are now automatically 


provable using termination proving 
techniques. 12,29 With every month, we 
now see more powerful applications 
of automatic termination proving. As 
an example, recent work has demon¬ 
strated the utility of automatic ter¬ 
mination proving to the problem of 
showing concurrent algorithms to be 
non-blocking. 20 With further research 
and development, we will see more 
powerful and more scalable tools. 

We could also witness a shift in the 
power of software, as techniques from 
termination proving could lead to 
tools for other problems of equal dif¬ 
ficulty. Whereas in the past a software 
developer hoping to build practical 
tools for solving something related to 
termination might have been fright¬ 
ened off by a colleague’s retort “but 
that’s like the termination problem,” 
perhaps in the future the developer 
will instead adapt techniques from 
within modern termination provers 
in order to develop a partial solution 
to the problem of interest. 

The purpose of this article is to fa¬ 
miliarize the reader with the recent 
advances in program termination 
proving, and to catalog the underly¬ 
ing techniques for those interested in 


Turing’s Classic Method 
and Disjunctive 
Well-Foundness 

Formally proving program termination amounts to proving the program’s transition 
relation R to be well-founded. If (.S’, >) is a well-order then > is a well-founded relation. 
Furthermore, any map/into S defines a well-founded relation, by lifting > via f that 
is, {(s, t) |/(s) >/{/)[. Turing’s method 39 of proving a program’s transition relation R 
well-founded amounts to finding a map/into a well-order, which defines a termination 
argument T = {(s, t) |/(s) >f{t )}. To prove the validity of Twe must show I? C T. From the 
well-foundedness of Tand the fact that every sub-relation of a well-founded relation is 
well-founded follows thatR is well-founded. 

In this article we are using the phrase disjunctive termination argument to refer to 
a disjunctively well-founded transition invariant . 31 This is a finite union T, U ... U T n of 
well-founded relations that contains R+, which is the transitive closure of the transition 
relation of the program, as a superset, such as, R+ C T, U ... U T„. 

Usually, each T,,..., T„ will be constructed as above via some map into a well-order. 
Note that the non-reflexive transitive closure (the + in R+) is crucial. It is not sufficient 
to show that R C T, U ... U T„„ as the union of well-founded relations is not guaranteed 
to be well-founded. It is the transitive closure that makes checking the subset inclusion 
more difficult in practice. 

The recent approaches for proving termination for general programs 3 ' 4 ' 9 ’ 12 ’ 14 ’ 32 are 
based on the proof rule of disjunctively well-founded transition invariants. The proof 
rule itself is based on Ramsey’s theorem , 34 and it has been developed in the effort to 
give a logical foundation to the termination analysis based on size-change graphs . 24 The 
principle expressed by the proof rule appears implicitly already in previously developed 
termination algorithms for rewrite systems and logic and functional programs, see 
refs 10 ’ 15 ’ 17> 24 


adapting the techniques to other do¬ 
mains. We also discuss current work 
and possible avenues for future inves¬ 
tigation. Concepts and strategies will 
be introduced informally, with cita¬ 
tions to original papers for those inter¬ 
ested in more detail. Several sidebars 
are included for readers with back¬ 
grounds in mathematical logic. 

Disjunctive Termination Arguments 

Thirteen years after publishing his 
original undecidability result, Turing 
proposed the now classic method of 
proving program termination. 39 His 
solution divides the problem into two 
parts: 

Termination argument search: Find 
a potential termination argument in 
the form of a function that maps every 
program state to a value in a math¬ 
ematical structure called a well-order. 
We will not define well-orders here, 
the reader can assume for now that we 
are using the natural numbers (a.k.a. 
the positive integers). 

Termination argument checking: 
Proves the termination argument to 
be valid for the program under con¬ 
sideration by proving that result of the 
function decreases for every possible 
program transition. That is, if/is the 
termination argument and the pro¬ 
gram can transition from some state s 
to state s', then ffsj >f(s'). 

(Readers with a background in logic 
may be interested in the formal expla¬ 
nation contained in the sidebar here.) 

A well-order can be thought of as a 
terminating program—in the exam¬ 
ple of the natural numbers, the pro¬ 
gram is one that counts from some 
initial value in the natural numbers 
down to 0. Thus, no matter which ini¬ 
tial value is chosen the program will 
still terminate. Given this connection 
between well-orders and terminat¬ 
ing programs, in essence Turing is 
proposing that we search for a map 
from the program we are interested in 
proving terminating into a program 
known to terminate such that all steps 
in the first program have analogous 
steps in the second program. This 
map to a well-order is usually called a 
progress measure or a ranking function 
in the literature. Until recently, all 
known methods of proving termina¬ 
tion were in essence minor variations 
on the original technique. 
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The problem with Turing’s meth¬ 
od is that finding a single, or mono¬ 
lithic, ranking function for the whole 
program is typically difficult, even for 
simple programs. In fact, we are often 
forced to use ranking functions into 
well-orders that are much more com¬ 
plex than the natural numbers. Luck¬ 
ily, once a suitable ranking function 
has been found, checking validity is in 
practice fairly easy. 

The key trend that has led toward 
current progress in termination prov¬ 
ing has been the move away from the 
search for a single ranking function 
and toward a search for a set of rank¬ 
ing functions. We think of the set as a 
choice of ranking functions and talk 
about a disjunctive termination argu¬ 
ment. This terminology refers to the 
proof rule of disjunctively well-found¬ 
ed transition invariants. 31 The recent 
approaches for proving termination 
for general programs 3,4 ’ 9 ' 12 ' 14 ’ 26 ’ 32 are 
based on this proof rule. The proof 
rule itself is based on Ramsey’s theo¬ 


rem, 34 and it has been developed in 
the effort to give a logical foundation 
to the termination analysis based on 
size-change graphs. 24 

The principle it expresses appears 
implicitly in previously developed ter¬ 
mination algorithms for rewrite sys¬ 
tems, logic, and functional programs, 
see refs 10 . 15 . 17 . 24 . 

The advantage to the new style of 
termination argument is that it is 
usually easier to find, because it can 
be expressed in small, mutually in¬ 
dependent pieces. Each piece can be 
found separately or incrementally us¬ 
ing various known methods for the 
discovery of monolithic termination 
arguments. As a trade-off, when using 
a disjunctive termination argument, a 
more difficult validity condition must 
be checked. This difficulty can be mit¬ 
igated thanks to recent advances in as¬ 
sertion checking tools (as discussed in 
a later section). 

Example using a monolithic termina¬ 
tion argument. Consider the example 


code fragment in Figure 1. In this code 
the collection of user-provided input is 
performed via the function input(). 
We will assume the user always enters 
a new value when prompted. Further¬ 
more, we will assume for now that vari¬ 
ables range over possibly negative in¬ 
tegers with arbitraiy precision (that is, 
mathematical integers as opposed to 
32-bit words, 64-bit words, and so on). 
Before reading further, please answer 
the question: “Does this program ter¬ 
minate, no matter what values the user 
gives via the input () function?” The 
answer is given below. c 

Using Turing’s traditional method 
we can define a ranking function from 
program variables to the natural num¬ 
bers. One ranking function that will 
work is 2x + y, though there are many 
others. Here we are using the formula 
2x + y as shorthand for a function 
that takes a program configuration 
as its input and returns the natural 
number computed by looking up the 
value of x in the memory, multiply¬ 
ing that by 2 and then adding in y’s 
value—thus 2x + y represents a map¬ 
ping from program configurations to 
natural numbers. This ranking func¬ 
tion meets the constraints required 
to prove termination: the valuation of 
2x + y when executing at line 9 in the 
program will be strictly one less than 
its valuation during the same loop 
iteration at line 4. Furthermore, we 
know the function always produces 
natural numbers (thus it is a map into 
a well-order), as 2x + y is greater than 
0 at lines 4 through 9. 

Automatically proving the valid¬ 
ity of a monolithic termination argu¬ 
ment like 2x + y is usually easy using 
tools that check verification condi¬ 
tions (for example, Slam 2 ). However, 
as mentioned previously, the actual 
search for a valid argument is fa¬ 
mously tricky. As an example, consid¬ 
er the case in Figure 2, where we have 
replaced the command “y := y + 1;” 
in Figure 1 with “y := input ();”. In 
this case no function into the natural 
numbers exists that suffices to prove 
termination; instead we must resort 
to a lexicographic ranking function 
(a ranking function into ordinals, a 
more advanced well-order than the 
naturals). 
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Example using a disjunctive termi¬ 
nation argument. Following the trend 
toward the use of disjunctive termina¬ 
tion arguments, we could also prove 
the termination of Figure 1 by defin¬ 
ing an argument as the unordered 
finite collection of measures x and 
y. The termination argument in this 
case should be read as: 

x goes down by at least 1 and is larger than 0. 
or 

y goes down by at least 1 and is larger than 0 

We have constructed this termina¬ 
tion argument with two ranking func¬ 
tions: x and y. The use of “or” is key: 
the termination argument is modu¬ 
lar because it is easy to enlarge using 
additional measures via additional 
uses of “or.” As an example, we could 
enlarge the termination argument 
by adding “or 2w - y goes down by 
at least 1 and is greater than 1,000.” 
Furthermore, as we will discuss later, 
independently finding these pieces of 
the termination argument is easier in 
practice than finding a single mono¬ 
lithic ranking function. 

The expert reader will notice the 
relationship between our disjunctive 
termination argument and complex 
lexicographic ranking functions. The 
advantage here is that we do not need 
to find an order on the pieces of the 
argument, thus making the pieces of 
the argument independent from one 
another. 

The difficulty with disjunctive ter¬ 
mination arguments in comparison to 
monolithic ones is that they are more 
difficult to prove valid: for the benefit 
of modularity we pay the price in the 
fact that the termination arguments 
must consider the transitions in all 
possible loop unrollings and not just 
single passes through a loop. That is to 
say: the disjunctive termination argu¬ 
ment must hold not only between the 
states before and after any single itera¬ 
tion of the loop, but before and after 
any number of iterations of the loop 
(one iteration, two iterations, three 
iterations, and so on). This is a much 
more difficult condition to automati¬ 
cally prove. In the case of Figure 1 we 
can prove the more complex condition 
using techniques described later. 

Note that this same termination ar¬ 
gument now works for the tricky pro¬ 


gram in Figure 2, where we replaced “y 
:= y+l;”with“y := input ();.” On 
every possible unrolling of the loop we 
will still see that either x or y has gone 
down and is larger than 0. 

To see why we cannot use the same 
validity check for disjunctive termina¬ 
tion arguments as we do for monolith¬ 
ic ones, consider the slightly modified 
example in Figure 3. For every single 
iteration of the loop it is true that ei¬ 



ther x goes down by at least one and 

I x is greater than 0 or y goes down by 
at least one and y is greater than 0. 
Yet, the program does not guarantee 
termination. As an example input se¬ 
quence that triggers non-termination, 
consider 5, 5, followed by 1, 0, 1, 0, 1, 
0, .... If we consider all possible unroll¬ 
ings of the loop, however, we will see 
that after two iterations it is possible 
(in the case that the user suDDlied the 



1 Figure 5. Encoding of termination argument validity. 

1 

copied := 0; 

2 

X : = 

input () ; 

3 

y : = 

input (); 

4 

while 

x > 0 and y > 0 do 

5 


if copied = 1 then 

6 


assert (oldx s x + 1 and oldx > 0) ; 

7 


elsif input () = 1 then 

8 


copied := 1; 

9 


oldx := x; 

10 


oldy := y; 

11 


fi 

12 


if input () = 1 then 

13 


x : = x - 1; 

14 


y := y + l; 

15 


else 

16 


*c 

n 

17 


fi 

18 

done 


Encoding of termination argument validity using the program from Figure 1 and the termination 

argument “ 

x goes down by at least one and is larger than 0." The black code comes directly from 

Figure 1. The code in red implements the encoding of validity with an assertion statement. 
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Implementation Strategies 

Here, we give a brief summary of implementation strategies based on disjunctive 
termination arguments deployed by the recent termination checkers: 

Refinement? 1 * In Cook et al ., 14 the termination argument begins with 0 . We first 
attempt to prove that K+Cp. When this proof fails, rank function synthesis is applied 
to the witness, thus giving a refinement Ti to the argument, which is then rechecked 
R+ C 0 U T u This process is repeated until a valid argument is found or a real 
counterexample is found. 

In Chawdhary et al ., 9 the termination argument Tis constructed following the 
structure of the transition relation R = Ri U ... U R,„ by using a ranking function 
synthesis procedure, which is used to compute a well-founded overapproximation 
WF(X ) of a binary relation X. The initial candidate T = UF(Ri ) U ... U WF (R,„) is extended 
with WF (WF (Ri) ° Rj) and so on until the fixpoint is reached. 

Variance analysis ? 31 As described in some detail in this article, the approach from 
Berdine et al . 3 and Podelski et al . 32 uses program transformations and abstract 
interpretation for invariants to compute an overapproximation Ti; 7i,... , 7’,, such that 
R+ C 7i U 7i ... U T„. It then uses rank function synthesis to check that each T, is well- 
founded. 

In contrast to the refinement-based methods, variance analysis always terminates, 
but may return “don’t know” in cases when a refinement-based method succeeds. 


inputs 1 and 0 during the two loop 
iterations) that neither x nor y went 
down, and thus the disjunctive termi¬ 
nation argument is not valid for the 
program in Figure 3. 

Argument Validity Checking 

While validity checking for disjunc¬ 
tive termination arguments is more 
difficult than checking for mono¬ 
lithic arguments, we can adapt the 
problem statement such that recently 
developed tools for proving the valid¬ 
ity of assertions in programs (such as 
Slam 2 ). 

An assertion statement can be put 
in a program to check if a condition 
is true. For example, assert(y > lb- 
checks that y > 1 after executing the 
command. We can use an assertion 
checking tool to formally investigate at 
compile time whether the conditions 
passed to assertion statements always 
evaluate to true. For example, most as¬ 
sertion checking tools will be able to 
prove the assert statement at line 3 
in Figure 4 never fails. Note that com- 
pile-time assertion checking is itself 
an undecidable problem, although it 
is technically in an easier class of dif¬ 
ficulty than termination. d 

The reason that assertion checking 
is so important to termination is the 
validity of disjunctive termination ar¬ 
guments can be encoded as an asser¬ 
tion statement, where the statement 
fails only in the case that the termina¬ 
tion argument is not valid. Once we are 
given an argument of the form T, or T 2 
or ... or T„, to check validity we simply 
want to prove the following statement: 

Each time an execution passes 
through one state and then through 
another one, T 2 or T 2 or ... or T„ holds 
between these two states. That is, there 
does not exist a pair of states, one be¬ 
ing reachable from the other, possibly 
via the unrolling of a loop, such that 
neither T) nor T 2 nor... nor T n holds be¬ 
tween this pair of states. 

This statement can be verified a 
program transformation where we 
introduce new variables into the pro¬ 
gram to record the state before the 
unrolling of the loop and then use 


d Checking validity of an assertion statement is 
an undecidable but co-recursively enumerable 
problem, whereas termination is neither r.e. 
nor co-r.e. problem. 


an assertion statement to check the 
termination argument always holds 
between the current state and the re¬ 
corded state. If the assertion checker 
can prove the assert cannot fail, it has 
proved the validity of the termination 
argument. We can use encoding tricks 
to force the assertion checker to con¬ 
sider all possible unrollings. 

Figure 5 offers such an example, 
where we have used the termination 
argument “x goes down by at least one 
and x is greater than 0” using the en¬ 


coding given in Cook et al. 14 The new 
code (introduced as a part of the en¬ 
coding) is given in red, whereas the 
original program from Figure 1 is in 
black. We make use of an extra call to 
input () to decide when the unroll¬ 
ing begins. The new variables oldx 
and oldy are used for recording a state. 
Note that the assertion checker must 
consider all values possibly returned 
by input () during its proof, thus the 
proof of termination is valid for any 
starting position. This has the effect of 


1 Figure 6. Encoding of termination argument validity using previous program. I 

1 

copied : = 0; 

2 

x : = 

input () ; 

3 

y : = 

input(); 

4 

while 

x > 0 and y > 0 do 

5 


if copied = 1 then 

6 


assert ( (oldx s x + 1 and oldx > 0) 

7 


or 

8 


(oldy 2 y + 1 and oldy > 0) 

\ . 

10 


) / 

elsif input () = 1 then 

11 


copied := 1; 

12 


oldx := x; 

13 


oldy := y; 

14 


fi 

15 


if input () = 1 then 

16 


X : = x - 1 ; 

17 


y := y + i; 

18 


else 

19 


y := y - 1; 

20 


fi 

21 

done 


Encoding of termination argument validity using the program from Figure 1 and the termination 
argument “x goes down by at least one and is larger than 0 or y goes down by at least one 
and is larger than 0." The black code comes directly from Figure 1. The code in red implements 
the encoding of validity with an assertion statement. 
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considering any possible unrolling of 
the loop. After some state has been re¬ 
corded, from this point out the termi¬ 
nation argument is checked using the 
recorded state and the current state. In 
this case the assertion can fail, mean¬ 
ing that the termination argument is 
not valid. 

If we were to attempt to check this 
condition in a naive way (for example, 
by simply executing the program) we 
would never find a proof for all but the 
most trivial of cases. Thus, assertion 
checkers must be cleverly designed to 
find proofs about all possible execu¬ 
tions without actually executing all of 


the paths. A plethora of recently devel¬ 
oped techniques now make this pos¬ 
sible. Many recent assertion checkers 
are designed to produce a path to a bug 
in the case that the assertion statement 
cannot be proved. For example, a path 
leading to the assertion failure is 1 —^ 
2 —> 3 ^ 4 —> 5 ^ 7 ^ 8 —> 9 ^ 10 ^ 
11 -► 12 -> 16 -)■ 17 -► 4 -► 5 -► 6. This 
path can be broken into parts, each 
representing different phases of the ex¬ 
ecution: the prefix-path 1 —> 2 —> 3 —> 
4 is the path from the program initial 
state to the recorded state in the failing 
pair of states. The second part of the 
path 4 —> 5 —>... 5 —> 6 represents how 


we reached the current state from the 
recorded one. That is: this is the unroll¬ 
ing found that demonstrates that the 
assertion statement can fail. What we 
know is that the termination argument 
does not currently cover the case where 
this path is repeated forever. 

See Figure 6 for a version using the 
same encoding, but with the valid ter¬ 
mination argument: 

x goes down by at least 1 and is larger than 0 
or 

y goes down by at least 1 and is larger than 0. 

This assertion cannot fail. The fact 
that it cannot fail can be proved by a 
number of assertion verification tools. 

Finding Termination Arguments 

We have examined how we can check 
a termination argument’s validity via 
a translation to a program with an as¬ 
sertion statement. We now discuss 
known methods for finding monolith¬ 
ic termination arguments. 

Rank function synthesis. In some 
cases simple ranking functions can 
be automatically found. We call a 
ranking function simple if it can be 
defined by a linear arithmetic expres¬ 
sion (for example, -3x = -2y + 100). 
The most popular approach for find¬ 
ing this class of ranking function uses 
a result from Farkas 16 together with 
tools for solving linear constraint sys¬ 
tems. (See Colon and Sipma 11 or Polel- 
ski and Rybalchecko 30 for examples 
of tools using Farkas’ lemma.) Many 
other approaches for finding rank¬ 
ing functions for different classes of 
programs have been proposed (see 
refs 1 ' 6-8 ' 19,37 ). Tools for the synthesis of 
ranking functions are sometimes ap¬ 
plied directly to programs, but more 
frequently they are used (on small 
and simplified program fragments) 
internally within termination proving 
tools for suggesting the single ranking 
functions that appear in a disjunctive 
termination argument. 

Termination analysis. Numerous 
approaches have been developed for 
finding disjunctive termination argu¬ 
ments in which—in effect—the valid¬ 
ity condition for disjunctive termina¬ 
tion arguments is almost guaranteed 
to hold by construction. In some cas¬ 
es—for example, Berdine et al. 3 —to 
prove termination we need only check 
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that the argument indeed represents a 
set of measures. In other cases, such 
as Lee et al. 24 or Manolios and Vroon, 26 
the tool makes a one-time guess as to 
the termination argument and then 
checks it using techniques drawn from 
abstract interpretation. 

Consider the modified program 
in Figure 7. The termination strat¬ 
egy described in Berdine et al. 3 and 
Podelski and Rybalchenko 32 essen¬ 
tially builds a program like this and 
then applies a custom program analy¬ 
sis to find the following candidate ter¬ 
mination argument: 

(copied * 1) or 

(oldx > x + 1, oldx > 0, oldy 

> 0, x a 0, y > 0) or 

(oldx > x, oldy > y + 1, oldx 

> 0, oldy > 0, x > 0, y > 0) 

for the program at line 4—meaning we 
could pass this complex expression to 
the assertion at line 4 in Figure 7 and 
know that the assertion cannot fail. 
We know this statement is true of any 
unrolling of the loop in the original 
Figure 1. What remains is to prove that 
each piece of the candidate argument 
represents a measure that decreases— 
here we can use rank function synthe¬ 
sis tools to prove that oldx > x + 1 and 
oldx > 0 . . . represents the measure 
based on x. If each piece between the 
ors in fact represents a measure (with 
the exception of copied * 1 which 
comes from the encoding) then we 
have proved termination. 

One difficulty with this style of ter¬ 
mination proving is that, in the case 
that the program doesn’t terminate, 
the tools can only report “unknown,” 
as the techniques used inside the ab¬ 
stract interpretation tools have lost 
so much detail that it is impossible 
to find a non-terminating execution 
from the failed proof and then prove it 
non-terminating. The advantage when 
compared to other known techniques 
is it is much faster. 

Finding arguments by refinement. 
Another method for discovering a ter¬ 
mination argument is to follow the ap¬ 
proach of Cook et al. 14 or Chawdhary 
et al. 9 and search for counterexamples 
to (possibly invalid) termination argu¬ 
ments and then refine them based on 
new ranking functions found via the 
counterexamples. 



In recent years, 
powerful new 
termination tools 
have emerged that 
return “unknown” 
infrequently enough 
that they are useful 
in practice. 



Recall Figure 5, which encoded the 
invalid termination argument for the 
program in Figure 1, and the path lead¬ 
ing to the failure of the assertion: is 1 
^2^3—>4—>5^7—>8—>9—>10 
-> 11 -> 12 -> 16 -> 17 -> 4 -> 5 -> 6. 
Recall this path represents two phases 
of the program’s execution: the path 
to the loop, and some unrolling of the 
loop such that the termination con¬ 
dition doesn’t hold. In this case the 
path 4 —> 5 —>... 6 represents how we 
reached the second failing state from 
the first. This is a counterexample to 
the validity of the termination argu¬ 
ment, meaning that the current ter¬ 
mination argument does not take this 
path and others like it into account. 

If the path can be repeated forever 
during the program’s execution then 
we have found a real counterexample. 
Known approaches (for example, Gup¬ 
ta et al. 21 ) can be used to try and prove 
this path can be repeated forever. In 
this case, however, we know that the 
path cannot be repeated forever, as 
y is decremented on each iteration 
through the path and also constrained 
via a conditional statement to be posi¬ 
tive. Thus this path is a spurious coun¬ 
terexample to termination and can 
be ruled out via a refinement to the 
termination argument. Again, using 
rank function synthesis tools we can 
automatically find a ranking function 
that demonstrates the spuriousness of 
this path. In this case a rank function 
synthesis tool will find y, meaning that 
the reason this path cannot be repeat¬ 
ed forever is that “y always goes down 
by at least one and is larger than 0.” We 
can then refine the current termina¬ 
tion argument used in Figure 5: 

x goes down by at least 1 and is larger than 0 
with the larger termination argument: 
x goes down by at least 1 and is larger than 0 
or 

y goes down by at least 1 and is larger than 0 

We can then check the validity of 
this termination argument using a tool 
such as IMPACT on the program in Fig¬ 
ure 6. IMPACT can prove this assertion 
never fails, thus proving the termina¬ 
tion of the program in Figure 1. 

Further Directions 

With fresh advances in methods for 
proving the termination of sequen- 
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tial programs that operate over math¬ 
ematical numbers, we are now in the 
position to begin proving termination 
of more complex programs, such as 
those with dynamically allocated data 
structures, or multithreading. Fur¬ 
thermore, these new advances open 
up new potential for proving proper¬ 
ties beyond termination, and finding 
conditions that would guarantee ter¬ 
mination. We now discuss these av¬ 
enues of future research and develop¬ 
ment in some detail. 

Dynamically allocated heap. Con¬ 
sider the C loop in Figure 8, which 
walks down a list and removes links 
with data elements equaling 5. Does 
this loop guarantee termination? 
What termination argument should 
we use? 

The problem here is that there are 
no arithmetic variables in the program 
from which we can begin to construct 
an argument—instead we would want 
to express the termination argument 
over the lengths of paths to NULL via 
the next field. Furthermore, the pro¬ 
grammer has obviously intended for 
this loop to be used on acyclic sin¬ 
gly linked lists, but how do we know 
that the lists pointed to by head will 
always be acyclic? The common solu¬ 
tion to these problems is to use shape 
analysis tools (which are designed to 


automatically discover the shapes of 
data-structures) and then to create 
new auxiliary variables in the program 
that track the sizes of those data struc¬ 
tures, thus allowing for arithmetic 
ranking functions to be more easily 
expressed (examples include refs 4,5 ’ 25 ). 
The difficultly with this approach is 
that we are now dependent on the ac¬ 
curacy and scalability of current shape 
analysis tools—to date the best known 
shape analysis tool 40 supports only 
lists and trees (cyclic and acyclic, sin¬ 
gly and doubly linked) and scales only 
to relatively simple programs of size 
less than 30,000 LOC. Furthermore, 
the auxiliary variables introduced by 
methods such as Magill et al. 25 some¬ 
times do not track enough informa¬ 
tion in order to prove termination (for 
example, imagine a case with lists of 
lists in which the sizes of the nested 
lists are important). In order to im¬ 
prove the state of the art for termina¬ 
tion proving of programs using data 
structures, we must develop better 
methods of finding arguments over 
data structure shapes, and we must 
also improve the accuracy and seal- 
ability of existing shape analysis tools. 

Bit vectors. In the examples used 
until now we have considered only 
variables that range over mathemati¬ 
cal numbers. The reality is that most 


programs use variables that range 
over fixed-width numbers, such as 
32-bit integers or 64-bit floating¬ 
point numbers, with the possibility 
of overflow or underflow. If a program 
uses only fixed-width numbers and 
does not use dynamically allocated 
memory, then termination proving is 
decidable (though still not easy). In 
this case we simply need to look for a 
repeated state, as the program will di¬ 
verge if and only if there exists some 
state that is repeated during execu¬ 
tion. Furthermore, we cannot ignore 
the fixed-width semantics, as over¬ 
flow and underflow can cause non¬ 
termination in programs that would 
otherwise terminate, an example is 
included in Figure 9. Another com¬ 
plication when considering this style 
of program is that of bit-level opera¬ 
tions, such as left- or right-shift. 

Binary executables. Until now we 
have discussed proving termination of 
programs at their source level, perhaps 
in C or Java. The difficulty with this 
strategy is the compilers that then take 
these source programs and convert 
them into executable artifacts can in¬ 
troduce termination bugs that do not 
exist in the original source program. 
Several potential strategies could help 
mitigate this problem: We might tty to 
prove termination of the executable 
binaries instead of the source level 
programs, or we might try to equip 
the compiler with the ability to prove 
that the resulting binary program pre¬ 
serves termination, perhaps by first 
proving the termination of the source 
program and then finding a map from 
the binary to the source-level program 
and proving that the composition with 
the source-level termination argument 
forms a valid termination argument 
for the binary-level program. 

Non-linear systems. Current ter¬ 
mination provers largely ignore non¬ 
linear arithmetic. When non-linear 
updates to variables do occur (for ex¬ 
ample x : = y * z;), current termina¬ 
tion provers typically treat them as 
if they were the instruction x := in¬ 
put ();. This modification is sound— 
meaning when the termination prover 
returns the answer “terminating,” we 
know the proof is valid. Unfortunately, 
this method is not precise: the treat¬ 
ment of these commands can lead to 
the result “unknown” for programs 


Figure 10. Example of multi-threaded terminating producer/consumer program. 


while x > o do 




x : = x - 1 ; 

l 

while 

y > 0 do 

lock (lek) 

2 


lock (lek) 

b : = X ; 

3 


y = =b; 

unlock (lek) 

5 


unlock (lek) 

done 

6 

done 



To prove that the thread on the Left terminates we must assume that the thread on the right always 
calls unlock when needed. To prove that the thread on the right always calls unlock when needed, 
we must prove that the thread on the left always calls unlock when needed, and so on. 
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that actually terminate. Termination 
provers are also typically unable to find 
or check non-linear termination argu¬ 
ments (x 2 , for example) when they are 
required. Some preliminary efforts in 
this direction have been made, 1,6 but 
these techniques are weak. To improve 
the current power of termination prov¬ 
ers, further developments in non-lin¬ 
ear reasoning are required. 

Concurrency. Concurrency adds an 
extra layer of difficulty when attempt¬ 
ing to prove program termination. The 
problem here is that we must consider 
all possible interactions between con¬ 
currently executing threads. This is es¬ 
pecially true for modern fine-grained 
concurrent algorithms, in which 
threads interact in subtle ways through 
dynamically allocated data structures. 
Rather than attempting to explicitly 
consider all possible interleavings of 
the threads (which does not scale to 
large programs) the usual method for 
proving concurrent programs correct 
is based on rely-guarantee or assume- 
guarantee style of reasoning, which 
considers every thread in isolation 
under assumptions on its environ¬ 
ment and thus avoids reasoning about 
thread interactions directly. Much of 
the power of a rely-guarantee proof 
system (such as Jones 22 and Misra and 
Chandy 28 ) comes from the cyclic proof 
rules, where we can assume a proper¬ 
ty of the second thread while proving 
property of the first thread, and then 
assume the recently proved property 
of the first thread when proving the as¬ 
sumed property of the second thread. 
This strategy can be extended to live¬ 
ness properties using induction over 
time, for example, Gotsman et al. 20 and 
McMillan. 27 

As an example, consider the two 
code fragments in Figure 10. Imagine 
that we are executing these two frag¬ 
ments concurrently. To prove the ter¬ 
mination of the left thread we must 
prove that it does not get stuck waiting 
for the call to lock. To prove this we 
can assume the other thread will al¬ 
ways eventually release the lock—but 
to prove this of the code on the right 
we must assume the analogous prop¬ 
erty of the thread on the left, and so 
on. In this case we can certainly just 
consider all possible interleavings of 
the threads, thus turning the concur¬ 
rent program into a sequential model 


representing its executions, but this 
approach does not scale well to larger 
programs. The challenge is to develop 
automatic methods of finding non-cir¬ 
cular rely-guarantee termination argu¬ 
ments. Recent steps 20 have developed 
heuristics that work for non-blocking 
algorithms, but more general tech¬ 
niques are still required. 

Advanced programming features. 
The industrial adoption of high-level 
programming features such as virtual 
functions, inheritance, higher-order 
functions, or closures make the task of 
proving industrial programs more of a 
challenge. With few exceptions (such 
as Giesl et al. 18 ), this area has not been 
well studied. 

Untyped or dynamically typed pro¬ 
grams also contribute difficulty when 
proving termination, as current ap¬ 
proaches are based on statically dis¬ 
covering data-structure invariants and 
finding arithmetic measures in order 
to prove termination. Data in untyped 
programs is often encoded in strings, 
using pattern matching to marshal 
data in and out of strings. Termination 
proving tools for JavaScript would be 
especially welcome, given the havoc 
that nonterminating JavaScript causes 
daily for Web browsers. 

Finding preconditions that guarantee 
termination. In the case that a program 
does not guarantee termination from 
all initial configurations, we may want 
to automatically discover the condi¬ 
tions under which the program does 
guarantee termination. That is, when 
calling some function provided by a 
library: what are the conditions under 
which the code is guaranteed to return 
with a result? The challenge in this 
area is to find the right precondition: 
the empty precondition is correct but 
useless, whereas the weakest precon¬ 
dition for even very simple programs 
can often be expressed only in com¬ 
plex domains not supported by today’s 
tools. Furthermore, they should be 
computed quickly (the weakest pre¬ 
condition expressible in the target log¬ 
ic may be too expensive to compute). 
Recent work has shown some prelimi¬ 
nary progress in this direction. 13 ’ 33 

Liveness. We have alluded to the 
connection between liveness prop¬ 
erties and the program termination 
problem. Formally, liveness proper¬ 
ties expressed in temporal logics can 



With fresh 
advances in 
methods for 
proving the 
termination 
of sequential 
programs that 
operate over 
mathematical 
numbers, we are 
now in the position 
to begin proving 
termination of 
more complex 
programs. 
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be converted into questions of fair ter¬ 
mination —termination proving were 
certain non-terminating executions 
are deemed unfair via given fairness 
constraints, and thus ignored. Cur¬ 
rent tools, in fact, either perform this 
reduction, or simply require the user to 
express liveness constraints directly as 
the set of fairness constraints. 12,29 Nei¬ 
ther approach is optimal: the reduc¬ 
tion from liveness to fairness is ineffi¬ 
cient in the size of the conversion, and 
fairness constraints are difficult for 
humans to understand when used di¬ 
rectly. An avenue for future work would 
be to directly prove liveness properties, 
perhaps as an adaption of existing ter¬ 
mination proving techniques. 

Dynamic analysis and crash dumps 
for liveness bugs. In this article we have 
focused only on static, or compile-time, 
proof techniques rather than tech¬ 
niques for diagnosing divergence dur¬ 
ing execution. Some effort has been 
placed into the area of automatically 
detecting deadlock during execution 
time. With new developments in the 
area of program termination proving 
we might find that automatic methods 
of discovering livelock could also now 
be possible. Temporary modifications 
to scheduling, or other techniques, 
might also be employed to help pro¬ 
grams not diverge even in cases where 
they do not guarantee termination or 
other liveness properties. Some pre¬ 
liminary work has begun to emerge 
in this area (see Jula et al. 23 ) but more 
work is needed. 

Scalability, performance, and preci¬ 
sion. Scalability to large and complex 
programs is currently a problem for 
modern termination provers—cur¬ 
rent techniques are known, at best, to 
scale to simple systems code of 30,000 
lines of code. Another problem we face 
is one of precision. Some small pro¬ 
grams currently cannot be proved ter¬ 
minating with existing tools. Turing’s 
undecidability result, of course, states 
that this will always be true, but this 
does preclude us from improving pre¬ 
cision for various classes of programs 
and concrete examples. The most fa¬ 
mous example is that of the Collatz’ 
problem, which amounts to proving 
the termination or non-termination 
of the program in Figure 11. Currently 
no proof of this program’s termination 
behavior is known. 


Conclusion 

This article has surveyed recent ad¬ 
vances in program termination prov¬ 
ing techniques for sequential pro¬ 
grams, and pointed toward ongoing 
work and potential areas for future 
development. The hope of many tool 
builders in this area is that the current 
and future termination proving tech¬ 
niques will become generally avail¬ 
able for developers wishing to directly 
prove termination or liveness. We also 
hope that termination-related appli¬ 
cations—such as detecting livelock at 
runtime or Wang’s tiling problem— 
will also benefit from these advances. 
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